The present invention relates generally to process control systems and, more particularly, to the use of advanced control blocks, such as model predictive and neural network control blocks, in process control systems.
Process control systems, such as distributed or scalable process control systems like those used in chemical, petroleum or other processes, typically include one or more process controllers communicatively coupled each other, to at least one host or operator workstation and to one or more field devices via analog, digital or combined analog/digital buses. The field devices, which may be, for example valves, valve positioners, switches and transmitters (e.g., temperature, pressure and flow rate sensors), perform functions within the process,such as opening or closing valves and measuring process parameters. The process controller receives signals indicative of process measurements made by the field devices and/or other of information pertaining to the field devices, uses this information to implement a control routine and then generates control signals which are sent over the buses to the field devices to control the operation of the process. Information from the field devices and the controller is typically made available to one or more applications executed by the operator workstation to enable an operator to perform any desired function with respect to the process, such as viewing the current state of the process, modifying the operation of the process, etc.
In the past, conventional field devices were used to send and receive analog (e.g., 4 to 20 milliamp) signals to and from the process controller via an analog bus or analog lines. These 4 to 20 ma signals were limited in nature in that they were indicative of measurements made by the device or of control signals generated by the controller required to control the operation of the device. However, in the past decade or so, smart field devices including a microprocessor and a memory have become prevalent in the process control industry. In addition to performing a primary function within the process, smart field devices store data pertaining to the device, communicate with the controller and/or other devices in a digital or combined digital and analog format, and perform secondary tasks such as self-calibration, identification, diagnostics, etc. A number of standard and open smart device communication protocols such as the HART(copyright), PROFIBUS(copyright), WORLDFIP(copyright), Device-Net(copyright), and CAN protocols, have been developed to enable smart field devices made by different manufacturers to be used together within the same process control network.
Moreover, there has been a move within the process control industry to decentralize process control functions. For example, the all-digital, two-wire bus protocol promulgated by the Fieldbus Foundation, known as the FOUNDATION(copyright) Fieldbus (hereinafter xe2x80x9cFieldbusxe2x80x9d) protocol uses function blocks located in different field devices to perform control operations previously performed within a centralized controller. In particular, each Fieldbus field device is capable of including and executing one or more function blocks, each of which receives inputs from and/or provides outputs to other function blocks (either within the same device or within different devices), and performs some process control operation, such as measuring or detecting a process parameter, controlling a device or performing a control operation, like implementing a proportional-derivative-integral (PID) control routine. The different function blocks within a process control system are configured to communicate with each other (e.g., over a bus) to form one or more process control loops, the individual operations of which are spread throughout the process and are, thus, decentralized.
Process controllers are typically programmed to execute a different algorithm, sub-routine or control loop (which are all control routines) for each of a number of different loops defined for, or contained within a process, such as flow control loops, temperature control loops, pressure control loops, etc. Generally speaking, each such control loop includes one or more input blocks, such as an analog input (AI) function block, a single-output control block, such as a proportional-integral-derivative (PID) or a fuzzy logic control function block, and a single output block, such as an analog output (AO) function block. These control loops typically perform single-input/single-output control because the control block creates a single output used to control a single process input, such as a valve position, etc. However, in certain cases, the use of a number of independently operating, single-input/single-output control loops is not very effective because the process variables being controlled are effected by more than a single process input and, in fact, each process input may effect the state of many process outputs. An example of this might occur in, for example, a process having a tank being filled by two input lines, and being emptied by a single output line, each line being controlled by a different valve, and in which the temperature, pressure and throughput of the tank are being controlled to be at or near desired values. As indicated above, the control of the throughput, the temperature and the pressure of the tank may be performed using a separate throughput control loop, a separate temperature control loop and a separate pressure control loop. However, in this situation, the operation of the temperature control loop in changing the setting of one of the input valves to control the temperature within the tank may cause the pressure within the tank to increase, which; for example, causes the pressure loop to open the outlet valve to decrease the pressure. This action may then cause the throughput control loop to close one of the input valves, thereby effecting the temperature and causing the temperature control loop to take some other action. As will be understood in this example, the single-input/single-output control loops cause the process outputs (in this case, throughput, temperature and pressure) to oscillate without ever reaching a steady state condition, which is undesirable.
Model predictive control or other types of advanced control have been used in the past to perform control in these types of situations. Generally speaking, model predictive control is a multiple-input/multiple output control strategy in which the effects of changing each of a number of process inputs on each of a number of process outputs is measured and these measured responses are then used to create a model of the process. The model of the process is inverted mathematically and is then used as a multiple-input/multiple-output controller to control the process outputs based on changes made to the process inputs. In some cases, the process model includes a process output response curve for each of the process inputs and these curves may be created based on a series of, for example, pseudo-random step changes delivered to each of the process inputs. These response curves can be used to model the process in known manners. Model predictive control is known in the art and, as a result, the specifics thereof will not be described herein. However, model predictive control is described generally in Qin, S. Joe and Thomas A. Badgwell, xe2x80x9cAn Overview of Industrial Model Predictive Control Technology,xe2x80x9d AIChE Conference, 1996.
In the past, creating a model predictive controller and placing that controller in a process control network required a significant amount of time and effort and could be extremely expensive. Usually, to create a model predictive controller for a particular process, a process expert (typically an out-side consultant) was employed to come to the plant and observe the plant or process operation. After choosing the appropriate process inputs and outputs for the model predictive controller, the expert sat in the control room and instructed the operator to deliver a series of stepped input waveforms to each of the chosen process inputs and to measure the effect of each of these inputs on each of the chosen process outputs. After collecting all of the process data, the expert generally delivered the collected data to an off-line system. There, the expert ran a first routine to screen the collected data for the purpose of eliminating bad data, such as data collected when the process was not operating normally, was shut down or in which some other error was present which prevented the collected data from representing normal operation of the process. The off-line system then ran a second routine using the screened data to create a model of the process. Thereafter, the model of the process was inverted or used in other known manners to create a model predictive controller for the process. Once the model predictive controller was created, it then had to be inserted into the process control system which generally meant that a process engineer had to program the control routines already within the control system to deliver each of the specified controller inputs (i.e., process outputs) to the model predictive controller and to have the model predictive controller deliver each of the controller outputs (i.e., process inputs) to the appropriate place in the control system to perform control. Although some venders used the same names for the model predictive controller inputs and outputs as used in the process control routine or system, in some cases, it was necessary to match up the inputs and outputs of the model predictive controller to the process outputs and inputs, as defined within the process control system. In any event, the step of incorporating a model predictive controller into a process control system could require a great deal of programming effort.
Consequently, although generally known in the art, the creation of the process model from the collected data, the creation of the model predictive controller and the incorporation of this controller into a process is time consuming, generally requires the input of an expert and can be very expensive. In fact, it can take several months and cost hundreds of thousands of dollars to create a single model predictive controller for a process. Unfortunately for the process operator, changes in the process, such as those caused by aging of the process equipment, can force the created model predictive controller to be obsolete or mismatched to the process, which means that the whole process has to be performed again to create another model predictive controller.
Still further, because the model predictive controller was typically created by an off-line system, this controller was generally not integrated into the process control system in the same manner as single loop or other control routines executed by the control system and, therefore, required special graphics to be created for the user or operator to view the state and operation of the model predictive controller. For this reason, it was hard to incorporate model predictive controllers into process control systems, such as the DeltaV(trademark) control system sold by Fisher Rosemount Systems, Inc., which have a process control display mechanism integrated with the operation of control blocks or control loops within the controller. In fact, the DeltaV system provides different views, such as an engineer""s view, an operator""s view and the like which display operation of the process to a user. Once set up, these views are automatically updated by the operation of function blocks executed within, for example, the process controller. However, to add a view or other information screen for a model predictive controller designed off-line by a different system, special graphics displays had to be created, typically in a different format than that used by the DeltaV system.
While these problems exist for model predictive controllers, the same or similar problems exist in the development and use of other advanced multipleinput/multiple output control blocks or systems, such as neural network modeling or control systems, multi-variable fuzzy logic controllers, real time optimizers, etc.
According to one aspect of the invention, an advanced control block implements multiple-input/multiple-output control, such as model predictive control, neural network modeling or control, etc., within a process control system in a manner that is integrated with the control blocks implemented using a control paradigm, such as the Fieldbus paradigm. The advanced control block may be initiated by creating a control block having desired inputs and outputs to be connected to process outputs and inputs, respectively, for controlling a process. The control block may be intended to ultimately include, for example, a complete model predictive controller, but initially has a data collection routine and a waveform generator associated therewith. If desired, the control block may have control logic that is untuned or otherwise undeveloped because this logic is missing tuning parameters, matrix coefficients or other control parameters necessary to be implemented. The control block is placed within the process control system with the defined inputs and outputs communicatively coupled within the control system in the manner these inputs and outputs would be connected if the advanced control block was being used to control the process. During a test procedure, the control block systematically upsets each of the process inputs via the control block outputs using waveforms generated by the waveform generator specifically designed for use in developing a process model. Then, via the control block inputs, the control block coordinates the collection of data pertaining to the response of each of the process outputs to each of the generated waveforms delivered to each of the process inputs. This data may, for example, be sent to a data historian to be stored.
After sufficient data has been collected, a process modeling procedure is run in which a process model is generated from the collected data using, for example, a model predictive controller process model generation routine. Thereafter, an advanced control block logic parameter determination routine is used to create or developed the parameters needed by the control logic to be used to control the process. The control logic parameters and, if needed, the process model, are then downloaded to the control block to complete formation of the advanced control block so that the advanced control block, with the advanced control logic parameters and process model therein, can be used to control the process.
The advanced control block can be designed in the same format or according to the same programming paradigm as other control blocks within the process control system and, therefore, can support the same graphical views supported by the other blocks (or elements) within the process control routine. Thus, the advanced control block may have one or more graphical views to be displayed to one or more users and may send data to these views during operation of the advanced control block.
Furthermore, the process model generated by the process modeling procedure may be used to simulate operation of the process and/or to simulate interaction of the process and the advanced control block. In one case, a process simulation block may be created from the determined process model and this process simulation block may be communicatively connected to the created advanced control block to test the operation of the advanced control block before using the advanced control block to control the actual process. In another case, a process simulation block may be created using an altered version of the determined process model to reflect aging or other changes within the process. This simulation block may be communicatively connected to the advanced control block to simulate operation of the advanced control block in the presence of changes to the process to thereby determine the performance of the advanced control block in the presence of process model mismatch. In a still further case, a simulation block developed from the process model may be run in conjunction with the process and may be used to create virtual process outputs to be used as inputs for the advanced control block when, for example, a sensor measuring one of the actual process outputs fails. The simulated process outputs may also be compared to the actual process outputs to determine the amount of mismatch between the process and the process model used to create the advanced control block, i.e., the process/process-model mismatch.